Handling falsely doomed parents of nested transactions

ABSTRACT

Various technologies and techniques are disclosed for detecting falsely doomed parent transactions of nested children in transactional memory systems. When rolling back nested transactions, a release count is tracked each time that a write lock is released due to rollback for a given nested transaction. For example, a write abort compensation map can be used to track the release count for each nested transaction. The number of times the nested transactions releases a write lock is recorded in their respective write abort compensation map. The release counts can be used during a validation of a parent transaction to determine if a failed optimistic read is really valid. If an aggregated release count for the nested children transactions accounts for the difference in version numbers exactly, then the optimistic read is valid.

BACKGROUND

Software transactional memory (STM) is a concurrency control mechanismanalogous to database transactions for controlling access to sharedmemory in concurrent computing. A transaction in the context oftransactional memory is a piece of code that executes a series of readsand writes to shared memory. STM is used as an alternative totraditional locking mechanisms. STM allows concurrent programs to bewritten more simply. A transaction specifies a sequence of code that issupposed to execute as if it were executing in isolation. This illusionof isolation is achieved by fine-grained locking of objects, and byexecuting in a mode that allows the side-effects of the transaction tobe rolled back if the transaction is discovered to be in conflict withsome other transaction. We say that a data access is “transacted” if thecode generated for that access has been modified to include support forthese locking and rollback mechanisms.

Many STM systems support nested transactions, allowing efficientcomposition of different components authored using transactions. Anested transaction is considered closed if it its effects are part ofthe same isolation boundary as its containing, or parent, transaction.When a closed nested transaction commits, its effects do not becomevisible to the rest of the system. Instead, its effects become part ofthe parent transaction, still in progress, and will become visible tothe rest of the system only when the parent transaction finally commits.When a nested transaction rolls back, its temporary effects are undoneand the state of the parent transaction is restored to the point thatthe nested transaction began.

STM systems that use in-place writes and optimistic reads use a versionnumber associated with each lockable region of memory to indicate whenchanges are made to shared data. A reading transaction willoptimistically record the version number of the memory (object, cacheline, etc.) but not otherwise lock the data. The transaction may commitif the version number does not change over the life of the transaction.Writing transactions increment the version number when releasing theirwrite locks, either for commit or rollback. The version number must beincreased during rollback because the writing transaction temporarilyupdated data in-place. These updates are visible to the readingtransaction, and it must be notified that it cannot commit, havingpotentially read inconsistent data.

Nested transactions that write data not yet written by the parent mustincrement version numbers on rollback just like non-nested (top-level)transactions. However, consider the case where a parent transactionoptimistically reads a variable X and a nested child transaction writesto variable X for the first time. The parent will record the versionnumber of X in its log, say, version V1. The nested transaction willbegin and acquire a write lock on X. If the nested transaction commits,then there are no problems: the write lock is not released and istransferred to the parent and the parent remains consistent, able tocommit. However, if the nested transaction rolls back, for whateverreason, it must release the write lock and increment the version numberfor X to V2. The parent will appear to be inconsistent at commit time.The version of X is V2, but the parent read it at V1 and has no recordof who changed the version number to V2. It appears that the parent hasconflicted with another transaction, but in fact it was a nested childtransaction that caused the version number increase, and this is notactually a conflict. The parent has been doomed by its child's rollbackoperation. This problem causes STM systems to experience spuriousre-executions of parent transactions.

SUMMARY

Various technologies and techniques are disclosed for detecting falselydoomed parent transactions of nested children in transactional memorysystems. When rolling back nested transactions, a release count istracked each time that a write lock is released for a given nestedtransaction. For example, a write abort compensation map can be used totrack the release count for each lock released for each nestedtransaction that rolls back. The number of times the nested transactionsrelease a write lock is recorded in their respective write abortcompensation map. The release counts can be used during a validation ofa parent transaction to determine if an apparently invalid optimisticread is really valid.

In one implementation, while processing a parent transaction log, anywrite abort compensation maps seen for nested child transactions areaggregated into an aggregated write abort compensation map in theparent. If the optimistic read failed to validate due to a versionnumber mismatch, then the aggregated write abort compensation map isconsulted to retrieve a particular variable's write lock release countfor the nested child transactions. If a difference in version numbersexactly matches the write lock release count for the nested childtransactions, then the optimistic read is valid.

This Summary was provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic view of a computer system of oneimplementation.

FIG. 2 is a diagrammatic view of a transactional memory application ofone implementation operating on the computer system of FIG. 1.

FIG. 3 is a high-level process flow diagram for one implementation ofthe system of FIG. 1.

FIG. 4 is a process flow diagram for one implementation of the system ofFIG. 1 illustrating the stages involved in creating and maintainingwrite abort compensation maps.

FIG. 5 is a process flow diagram for one implementation of the system ofFIG. 1 illustrating the stages involved in aggregating write abortcompensation maps during transaction rollback.

FIG. 6 is a process flow diagram for one implementation of the system ofFIG. 1 illustrating the stages involved in using write abortcompensation maps during transaction validation to avoid falsely doomingparents of nested transactions.

DETAILED DESCRIPTION

The technologies and techniques herein may be described in the generalcontext as a transactional memory system, but the system also servesother purposes in addition to these. In one implementation, one or moreof the techniques described herein can be implemented as features withina framework program such as MICROSOFT® .NET Framework, or from any othertype of program or service that provides platforms for developers todevelop software applications. In another implementation, one or more ofthe techniques described herein are implemented as features with otherapplications that deal with developing applications that execute inconcurrent environments.

In one implementation, a transactional memory system is provided thatallows the false dooming of parent transactions of nested childtransactions to be detected and avoided. The term “doomed” as usedherein is meant to include transactions that will later be rolled backbecause they have performed one or more optimistic reads on one or morevariables that have subsequently been written by other transactions.When attempting to commit such a transaction, the failed optimisticreads will cause the transaction to roll back and re-execute. The term“falsely doomed” as used herein is meant to include any transaction thatappears to be doomed due to a failed optimistic read, but that isactually not doomed because the optimistic read was actually valid dueto operations performed by nested transactions. The term “nestedtransaction” as used herein is meant to include any transaction whoseeffects are enclosed within the isolation boundary of anothertransaction. The transaction that encloses the nested transaction iscalled the “parent” of the nested transaction, and the nestedtransaction is typically called the “child”. The number of times eachnested child releases a write lock is tracked in per-lock releasecounts. In one implementation, these counts are tracked in a write abortcompensation map. The term “write abort compensation map” as used hereinis meant to include a data structure that stores the per-lock releasecounts for each lock that each nested child releases. Multiple writeabort compensation maps can be aggregated into an aggregate map duringtransaction validation or roll back.

When validating a parent transaction, if an optimistic read failsvalidation, then the current aggregate write abort compensation map isconsulted to see if the difference in version numbers in a transactionalmemory word exactly matches the aggregate release count of the nestedchild transactions for that object or memory region. If so, then theoptimistic read is actually valid and the parent should not be falselydoomed. The term transactional memory word as used herein is meant toinclude a data structure provided for each transaction that tracksvarious information about the given transaction, such as lock status andversion number. For example, the TMW can include a version number and alist/count and/or indicator of readers. In one implementation, thelist/count and/or indicator of readers can include a count of the numberof readers accessing the particular value at a given point in time. Inanother implementation, the list/count and/or indicator of readers caninclude a list of the particular readers (e.g. pessimistic) accessingthe particular value at a given point in time. In yet anotherimplementation, the list/count and/or indicator of readers is simply aflag or other indicator to indicate that there are one or more readersaccessing the particular value at a given point in time. These are justexamples, and the use of the term TMW herein is meant to cover a varietyof mechanisms for tracking transaction statuses.

As shown in FIG. 1, an exemplary computer system to use for implementingone or more parts of the system includes a computing device, such ascomputing device 100. In its most basic configuration, computing device100 typically includes at least one processing unit 102 and memory 104.Depending on the exact configuration and type of computing device,memory 104 may be volatile (such as RAM), non-volatile (such as ROM,flash memory, etc.) or some combination of the two. This most basicconfiguration is illustrated in FIG. 1 by dashed line 106.

Additionally, device 100 may also have additionalfeatures/functionality. For example, device 100 may also includeadditional storage (removable and/or non-removable) including, but notlimited to, magnetic or optical disks or tape. Such additional storageis illustrated in FIG. 1 by removable storage 108 and non-removablestorage 110. Computer storage media includes volatile and nonvolatile,removable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules or other data. Memory104, removable storage 108 and non-removable storage 110 are allexamples of computer storage media. Computer storage media includes, butis not limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium which can be used tostore the desired information and which can accessed by device 100. Anysuch computer storage media may be part of device 100.

Computing device 100 includes one or more communication connections 114that allow computing device 100 to communicate with othercomputers/applications 115. Device 100 may also have input device(s) 112such as keyboard, mouse, pen, voice input device, touch input device,etc. Output device(s) 111 such as a display, speakers, printer, etc. mayalso be included. These devices are well known in the art and need notbe discussed at length here. In one implementation, computing device 100includes transactional memory application 200. Transactional memoryapplication 200 will be described in further detail in FIG. 2.

Turning now to FIG. 2 with continued reference to FIG. 1, atransactional memory application 200 operating on computing device 100is illustrated. Transactional memory application 200 is one of theapplication programs that reside on computing device 100. However, itwill be understood that transactional memory application 200 canalternatively or additionally be embodied as computer-executableinstructions on one or more computers and/or in different variationsthan shown on FIG. 1. Alternatively or additionally, one or more partsof transactional memory application 200 can be part of system memory104, on other computers and/or applications 115, or other suchvariations as would occur to one in the computer software art.

Transactional memory application 200 includes program logic 204, whichis responsible for carrying out some or all of the techniques describedherein. Program logic 204 includes logic for creating a write abortcompensation map (WACM) when a nested transaction rolls back andreleases a write lock for the first time 206 (as described below withrespect to FIG. 4); logic for recording in each entry in the WACM, thenumber of times a nested transaction released the write lock in a giventransactional memory word 208 (as described below with respect to FIG.4); logic for holding WACM in parent's transaction log 210 (as describedbelow with respect to FIG. 4); logic for using and updating same WACM ifa particular nested transaction re-executes and rolls back again 212 (asdescribed below with respect to FIG. 4); logic for aggregating WACM'S asappropriate 214 (as described below with respect to FIG. 5); logic forusing WACM's during transaction validation to determine if failedoptimistic read is really valid or invalid 216 (as described below withrespect to FIG. 6); and other logic for operating the application 220.

Turning now to FIGS. 3-6 with continued reference to FIGS. 1-2, thestages for implementing one or more implementations of transactionalmemory application 200 are described in further detail. In someimplementations, the processes of FIGS. 3-6 are at least partiallyimplemented in the operating logic of computing device 100. FIG. 3 is ahigh level process flow diagram for transactional memory application200. The process begins at start point 240. Any write lock releasedduring nested transaction rollback has the potential to doom the parenttransduction (stage 242). When rolling back a transaction, each timethat a version number is increased is remembered (stage 244). The systemtracks this information for each nested transaction that rolls back(stage 246). During transaction validation, the system uses thisinformation to determine whether a particular optimistic read thatfailed validation is actually valid because the difference was due tore-execution nested children (stage 248). These stages are described infurther detail in FIGS. 4-6. The process ends at end point 250.

FIG. 4 illustrates one implementation of the stages involved in creatingand maintaining write abort compensation maps. The process begins atstart point 270 with creating a write abort compensation map (WACM) thatis keyed by a unique lock identifier when a nested transaction rollsback and releases a write lock for the first time (stage 272). Eachentry in the WACM records the number of times the nested transactionreleased a write lock on a given transactional memory word (stage 274).

The WACM is held in a parent transaction's log and is ordered after alloptimistic reads made by the parent at the start of the nestedtransaction (stage 276). If a particular nested transaction re-executesand rolls back again, the system uses the same WACM and updates it withany new write lock release (stage 278). If the nested transactionacquires a lock again that it acquired on a previous execution, thecount for that transactional memory word is incremented in the WACM(stage 280). The process ends at end point 282.

FIG. 5 illustrates one implementation of the stages involved inaggregating WACM'S during transaction rollback. The process begins atstart point 290 with a nested transaction that was also the parent ofmany nested children over time possibly having multiple WACM's dispersedthroughout its log (stage 292). If multiple WACM'S are encounteredduring transaction rollback, then all WACM'S due to the nested childrenare aggregated into a single WACM and placed in the parent's log (stage294). The process ends at end point 296.

FIG. 6 illustrates one implementation of the stages involved in usingWACM'S during transaction validation to avoid falsely dooming parents ofnested transactions. The process begins at start point 310 withaggregating any WACM seen as optimistic read entries are processed intoa temporary WACM for the validation process while processing theparent's log in reverse (stage 312). If the optimistic read failed tovalidate due to a version number mismatch (decision point 314), then thetemporary WACM is consulted, using the TWM address as a key (stage 316).If there is a matching entry on that TMW address (decision point 318),then the system calculates whether the count associated with the entrymatches the difference in the version number exactly (decision point320). If the count matches the difference in the version number exactly(decision point 320), then the optimistic read is valid and thedifference was due solely to re-executing the nested children (stage322). If not, then the optimistic read is invalid and is due tocommit/rollback of the other transactions (stage 324). The stages arerepeated for the entire parent log (decision point 326). The processends at end point 328.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims. All equivalents, changes, andmodifications that come within the spirit of the implementations asdescribed herein and/or by the following claims are desired to beprotected.

For example, a person of ordinary skill in the computer software artwill recognize that the examples discussed herein could be organizeddifferently on one or more computers to include fewer or additionaloptions or features than as portrayed in the examples.

1. A method for avoiding falsely doomed parent transactions of nestedchildren in a transactional memory system comprising the steps of: whenrolling back nested transactions, tracking a release count each timethat a write lock is released; and during validation of a parenttransaction, using the release count to determine whether an optimisticread that failed validation is actually valid.
 2. The method of claim 1,wherein the failed validation is actually valid if a difference inversion numbers exactly matches the release count.
 3. The method ofclaim 1, wherein the release count is tracked in a write abortcompensation map.
 4. The method of claim 3, wherein the write abortcompensation map is created for each of the nested transactions.
 5. Themethod of claim 4, wherein the write abort compensation map is createdfor a respective one of the nested transactions when the respective onefirst rolls back and releases a write lock.
 6. The method of claim 4,wherein the write abort compensation map for each of the nestedtransactions are aggregated into an aggregate write abort compensationmap.
 7. The method of claim 6, wherein the aggregate write abortcompensation map is used while processing a transaction log of theparent transaction to determine if the optimistic read that failed isreally valid.
 8. The method of claim 7, wherein the transaction log ofthe parent is processed in a reverse order.
 9. A computer storage mediumhaving computer-executable instructions for causing a computer toperform steps comprising: creating a write abort compensation map for anested transaction; recording in the write abort compensation map anumber of times the nested transaction releases a write lock; and usingthe write abort compensation map during a validation of a parenttransaction to determine if a failed optimistic read is really valid.10. The computer storage medium of claim 9, wherein the write abortcompensation map is created when the nested transaction rolls back andreleases a write lock for a first time.
 11. The computer storage mediumof claim 9, wherein the failed optimistic read is really valid if adifference in version numbers exactly matches the number of times thenested transaction released the write lock.
 12. The computer storagemedium of claim 9, wherein the write abort compensation map is held intransaction log of the parent transaction.
 13. The computer storagemedium of claim 12, wherein the write abort compensation map is orderedafter all optimistic reads made by the parent transaction at a start ofthe nested transaction.
 14. The computer storage medium of claim 9,wherein the write abort compensation map is aggregated with other writeabort compensation maps encountered for other nested children to form anaggregated write abort compensation map during parent transactionrollback.
 15. The computer storage medium of claim 14, wherein theaggregated write abort compensation map is placed in a transaction logof the parent transaction.
 16. The computer storage medium of claim 15,wherein the aggregated write abort compensation map is placed in thetransaction log of the parent transaction when processing thetransaction log of the parent in a reverse order.
 17. A method for usingwrite abort compensation maps during transaction validation to avoidfalsely dooming parents of nested transactions comprising the steps of:while processing a parent log, aggregating any write abort compensationmaps seen in nested child transactions into an aggregated write abortcompensation map; if an optimistic read failed to validate due to aversion number mismatch, then consulting the aggregated write abortcompensation map to retrieve a write lock release count for the nestedchild transactions; and if a difference in version numbers exactlymatches the write lock release count for the nested child transactions,then the optimistic read is valid.
 18. The method of claim 17, whereinif the difference in version numbers does not exactly match the writerelease count for the nested child transactions, then the optimisticread is invalid.